[レポート]OpsJAWS Meetup#13に参加してきました #opsjaws
大栗です。
OpsJAWS Meetup#13 ~ 分散トレーシングにおけるAPM活用 ~に参加してきたので、レポートします。
ご挨拶、OpsJAWS紹介
日本ユニシス株式会社 会澤 康二 様
クラウドの運用ってなんだろう?
- 基盤が柔軟 -> 増え続ける運用対象
- スピードアップ -> 帰れない
- DevOps -> 仕事が増える
- サービス品質向上 -> 夜中の自動コール
- 画期的アーキテクチャ -> 運用でカバー
対象者:"運用"というワードに反応したかた
アンケートにご協力ください
分散アプリケーションの内部を可視化 AWS X-rayとは?
アマゾン ウェブ サービス ジャパン 畑 史彦 様
AWSのロゴが変わってます!
内容についての注意点
特に料金などは公式の情報を確認してください。
Webアプリケーション開発における課題
現在のWebアプリケ0ションのパフォーマンス・チューニングやデバックにおける課題
- モノリシックとマイクロサービス
- 分散アプリケ0ションはますます増加していく傾向
- モノリシックな(単一の)アプリケーション:分析やデバックは比較的単純
- 分散アプリケーション:分析やデバックが複雑
- プロダクションと開発環境
- プロダクション環境と開発環境の違い
- プロダクション環境の調査は複雑
- プロダクション環境を直接プロファイリングしプロダクション環境を直接デバックできたらどんなに楽か
AWS X-Rayによる解決
アプリケーションやその基盤サービス
What is X-Ray
- 分散アプリケーション内部の可視化と診断
X-Ray(レントゲン)
- 人体内部の分析や画像診断
AWS X-Ray(レントゲン)
- 分散アプリケーション内部の可視化と診断
サービスマップ
- 各ノードの呼出しの結果を色で分類し、割合を円グラフに表示する
- グリーン:呼出し成功
- レッド:5XX
- イエロー:4XX
- パープル:429
レイテンシの分散グラフ
- レイテンシをヒストグラムで表示
- X軸にかかった時間、Y軸にリクエストの割合
- 任意の範囲を選択
トレースのフィルタ
- エラーの検出:Exceptionの表示など
データ収集
AWS X-Rayの概念とコンポーネント
- トレース
- セグメント
- サブセグメント
- メタデータ/アノテーション
AWS X-Rayの概念
データ収集の動作
- メタデータを自動でキャプチャする機能を提供
- SDKからトラフィックを受信。データを一定時間バッファしたのちX−Ray APIに送信
アプリケーション内でのトレースの動作
アプリケーションにはX-Ray SDKを組み込む必要がある
AWS各サービスとの統合
AWS X-Rayがサポートしている言語
- Java
- Node.js
- C#
- Python
- Go
※ RubyのSDKをcookpadで公開している。
サポートされるトレースターゲット
- 各種AWSサービスへのアクセス:DynamoDB、SQS、S3、etc
- RDBへのクエリ:MySQL、PostgreSQL
- 外部へのHTTPリクエスト
- その他、サブセグメントデータを手動作成
Elastic Load Balancingとの統合
- ALBは受信したHTTPリクエストヘッダに対してトレースIDという値を追加する
- アプリケーション内でこのヘッダの値を記録しておく
アプリケーション実行環境との統合
- Amazon EC2
- AWS Elastic Beastalk
- Amazon ECS
- AWS Lambda
デモ
API GatewayからLambdaを呼び出す環境で、簡単にトレーシングを行うでもを披露していただきました。
ユースケース例
- 負荷試験時にAWS X-Rayを全面的に利用し、パフォーマンスチューニングを行う
- プロダクション環境は、サンプリングを行い統計的にモニタリング
- ステージング環境では全てのHTTPリクエストをトレースするように設定する
注意点
- デフォルトではサンプリングされる
- データの完全性は保証されない
- 直近30日冠のトレースデータが保存される
PythonでX-Rayを利用する場合は、以下のコードを追加します
from aws_xray_sdk.core import xray_recorder from aws_xray_sdk.core import patch_all patch_all()
まとめ
本番環境のアプリケーションの問題を検出し、パフォーマンスのボトルネックを可視化
分散アプリケーションの状態把握とデバッグを容易に
AWS X-Rayと各種AWSサービスとの強力なインテグレーション
マイクロサービスによるアプリ開発と分散トレーシングにおけるAPMの活用
日商エレクトロニクス 松尾 竹純 様/ 宮野 真冬 様
マイクロサービスの特徴と課題
マイクロサービス
- サービス相互をRESTの様なシンプルで軽量なAPIで連携する手法
マイクロサービスのメリット
- サービス単位チームごとに得意な言語やフレームワークで開発できる
- 小規模な単位で並列に開発でき、ビルドやテストの効率が上がる
- システム全体ではなく、サービスごとに変更やデプロイができる
- システム全体ではなく、サービスごとにスケールできる
マイクロサービスの課題
- システム全体を理解するのが困難
- 設計・実装の一貫性が維持しづらい
- システム全体の構成が複雑になる
マイクロサービスにおけるルートコーズ調査
- モノリシックシステム
- マイクロサービス:分散トレーシング
分散トレーシング
- できること
- ライフサイクルごとの追跡可視化
- 仕組み
- トレーサがリクエストヘッダにトレースIDを埋め込む
New Relic概要
インフラからアプリまで、フロントエンドからサーバーサイドまでSREのために開発されたフルスタックのパフォーマンス監視・分析プラットフォーム
Monitoring as a Service
- 監視の設定や設計不要でクラウド監視に最適
- 環境構築時にエージェントを仕込んでおくだけ
- デプロイと同時に監視開始
フルスタックの洞察
- クライアントサイド監視・分析
- サーバサイド監視・分析
市場シェア8割を超えるあpフォーマンス監視の定番
分散トレーシングのアルタナティブとしてのNew Relic活用
システム全体の構成の可視化
- サービスマップ:システム全体におけるマイクロサービス感のリモートサービスコールをトレースし、相関性をマップとして表示する
個々のマイクロサービスの処理状況の可視化
- リモートサービスコールの処理時間
- 内部プロセスの処理時間
- リクエスト/プロセスのリスト
- 個々のプロセスのコールマップ
- 個々のプロセスのパフォーマンス
関連先マイクロサービスの処理状況の可視化
- プロセスの時系列ブレークダウン
- 詳細情報へのドリルダウン
ルートコーズの特定
- ボトルネックに関するクエリレベルのトレース
- スレッドプロファイル
分散トレーシングにおけるNew Relic活用のメリット
- マイクロサービス間だけでなく、マイクロサービス内のプロセスも含めたルートコーズ分析が可能
- 直感的なボトルネック探索
クラウドネイティブ環境におけるマイクロサービス
実行環境とインフラの相関管理
- 個々のマイクロサービスごとの¥に実行インフラ情報を集計して、リソースプールとして分析
- ヘルスマップ
New Relic活用のメリットと課題
- 全てのユーザのリクエストをプロファイルしている訳ではない
- パフォーマンス以上の分析しかできない
おまけ
- AI/機械学習を活用したログ管理・分析がトレンドになりつつある
- トレースIDおよびすまんIDを用いない分散トレーシングが可能
- 相関制度および検知精度が課題
デモンストレーション
New Relicの始め方
まずは30日間無料トライアル
New Relicのサイトでは14日間無料ですが、日商エレクトロニクス株式会社のリンクから申し込むと30日間無料です。
https://contacts.nissho-ele.co.jp/newrelic_signup.html
安心の技術サポート
まとめ
- マイクロサービスの特徴と課題
- 分散トレーシング
- New Relic概要
- 分散トレーシングのオルタネイティブとしてのNre Relic活用
- New Relic活用のメリットと課題
- New Relicの始め方
さいごに
最近は様々なサービスコンポーネントを使用したりマイクロサービスの活用が進んでいると思います。すると全体を見通してパフォーマンスを分析することが難しくなってきます。以前にも増してX-RayやNew Relicなどを活用してパフォーマンスを分析すること重要になってきていることを感じました。